\textbf{Indicador de Funcionalidad Completa} \\
Con este indicador podemos ver la funcionalidad desarrollada, aquella que ya fue probada y liberada por QC, así como también la planificación para dichas tareas. 
En el caso que nos concierne se puede ver que QC tiene un retraso importante con respecto a lo planificado. Al día de la fecha tenemos solamente liberado aproximadamente el 50\% de lo que debería haber sido liberado.
También hay un atraso en cuanto a lo liberado por el equipo de desarrollo, aunque se esta dentro de un margen aceptable (80\%).
Estos excesivos atrasos se pueden deber a una mala planificación, a una sobrecarga de tareas en algún recurso o simplemente los recursos no rindieron como se esperaba. También puede darse por que se pensaba contar con determinada cantidad de recursos y estos fallaron fuera de lo estipulado(vacaciones, enfermedad, etc). Además como el equipo de desarrollo se atrasó, hace que la tarea de los demás que dependen de ellos se atrasen también. Obviamente si el equipo de QC tiene que testear funcionalidad, si esta todavía no esta desarrollada, no se puede testear. Por ultimo, también puede pasar que el equipo de desarrollo haya liberado un monton de funcionalidad y que esta posee muchos errores criticos por lo que QC no libera dicha funcionalidad(También podria ser que QC fuera muy exigente con sus pruebas). 
Por estos retrasos, la proxima entrega del 29-11 va a distar mucho de lo planificado. Asi, se debera hablar con el cliente acerca de retraso y ver que es lo que el cliente desea hacer(seguir con el proyecto, terminarlo, extender el tiempo del mismo, etc). Se pueden, dejar funcionalidades para la proxima version(si es que va  a haber otra), priorizar las funcionalidades faltantes y convenir con el cliente para desarrollar aquellas que le son mas importantes, etc. Para ir con numeros mas concretos al cliente se debe replanificar y estimar, con estos retrasos cuando se va a volver al rumbo con el proyecto. También se podria ver la posibilidad de agregar mas recursos al equipo de QC, que es el de mayor problema(obviamente esto hay que hablarlo con el cliente). \\

\textbf{Indicador de Evolución de la Prueba} \\
Con este indicador podemos ver los defectos que tiene el proyecto y el estado de los mismos.
En nuestro caso podemos ver que se abren más defectos de los que se cierran. Pero esta, es la tendecia durante todo el proyecto. De a poco se puede ver como la tendencia es que la cantidad de errores que aparecen por día empieza a disminuir, a la par que la cantidad de los errores corregidos por día empieza a aumentar, hasta que en un momento esta ultima es mayor que la primera(“bug convergence”). \\
Qué se lee? \\
Lo principal que observamos del gráfico es como la pendiente de la curva del total de defectos acumulados va disminuyendo mientras que la de la curva de defectos cerrados se mantiene, lo cual nos significa que estamos por el buen camino hacia la convergencia de bugs. Con respecto a como nos encontramos parados hacia la entrega de aceptación consideramos que un análisis de este indicador nos arroja un buen resultado ya que en la entrega anterior realizada el 15/11 se contaba con una relación similar entre defectos totales y defectos cerrados. Lo que tambien notamos, es que a pesar de que ya estamos en un punto en el cual la cantidad de defectos cerrados por dia es mayor que la cantidad encontrados, no podemos decir que esta tendencia sea definitiva, y que con un stock de 100 defectos sin cerrar aún, quizás plantear una entrega en producción en 1 semana no sea algo conveniente ya que se realizara una instalación con varios defectos sin solucionar ( esto es considerando el ritmo actual de trabajo ).
Cuáles son las posibles causas?
La causa posible que vemos es un mal desempeño del equipo de QC que no logra reducir la diferencia entre los defectos cerrados y los pendientes de una forma mas rápida, u otra posible razón es que el código entregado por desarrollo sea de pobre calidad, generando así que se le encuentren muchos defectos que deben ser atentidos. \\
Cuáles son los posibles impactos? \\
El impacto que mencionamos es que si no logramos reducir el nivel de defectos pendientes por debajo de los 100 no se podrá concretar una liberación en producción libre de defectos. Considerando que la primer entrega en producción es en una semana puede representar un gran problema. \\
Cuáles son las posibles acciones correctivas? \\
La principal acción correctiva que identificamos tiene que ver con aumentar la capacidad de corrección de defectos por día del equipo de QC para intentar llegar al hito del 6/12 y del 13/12 con pocos o ningún defecto critico. No planteamos mejorar la calidad del codigo porque ya existe un acumulado de 100 defectos que deben resolverse con lo cual intentar contratar personal mas capacitdado para replantear el proceso de liberación por parte de desarrollo nos parece que puede resultar contraproducente a esta altura. \\

\textbf{Indicador de Cobertura de la Prueba} \\
Qué se lee? \\
Observando el grafico notamos un marcado atraso en el calendario. Si bien se esperaban tener aproximadamente 750 casos de prueba, solamente han sido liberados unos 400 , y de esos incluso menos, unos 300, han sido marcados como “OK” es decir, sin errores. Se puede apreciar tambien que una gran parte del desfasaje entre lo planificado y lo obtenido se produce en el periodo de tiempo transcurrido entre las semanas del l 22/10 al 5/11. \\
Cuáles son las posibles causas? \\
Las posibles causas que identificamos tienen que ver con una sobre estimación de casi el doble de las posibilidades del equipo de desarrollo. O quizas una sub-estimacion , mas particular, de la dificultad de las tareas que el equipo tuvo que realizar en el periodo de tiempo mencionado anteriormente. Otra posibilidad es que el equipo de testing se haya retrasado en la ejecución de algún caso de prueba crucial que haya imposibilitado al equipo de desarrollo continuar con el proyecto, esto pensamos que es posible porque desde el 22/10 al 5/11 no observamos un aumento significativo en los casos de prueba cumplidos, a pesar de que se tenían entregas listas para probar. \\
Cuáles son los posibles impactos? \\
El impacto mas importante es que para  esta segunda liberacion no se va a llegar con todas las pruebas realizadas que se habia planificado, seguramente entregando un producto muy inestable y con gran cantidad de bugs que debieran no existir. Además , internamente, existe un impacto porque este nivel de atraso implicaría que se deben tomar acciones correctivas
Cuáles son las posibles acciones correctivas?
Las acciones correctivas que podriamos tomar tienen que ver con analizar lo sucedido en el periodo de tiempo en que se estanca la evolución de los casos de prueba, para poder plantear una solucion adecuada. Probablemente las soluciones que se terminen realizando tendrán que ver con mejorar la capacidad del equipo de desarrollo para aumentar la tasa de liberación de casos de prueba ya que es el principal problema que se observa. \\

\textbf{Análisis conjunto de los indicadores} \\
Haciendo un análisis conjunto observamos que el principal problema viene dado por un retraso en el equipo de QC para liberar las funcionalidades. Pensamos que esto puede estar causado por contar con pocos recursos en ese equipo, por ser un equipo con personal poco capacitado para la tarea, o que también puede deberse a que el código liberado por desarrollo es de pobre calidad y que entonces, no queda otra solución que demorarse en identificar defectos y proponer soluciones. En este sentido pensamos que no nos encontramos dentro de un margen seguro para la entrega de aceptacion del 29/11, ya que de no corregirse drásticamente la tendencia en los próximo dos días estaríamos entregando apenas diez funcionalidades probadas de las dieciocho planificadas. Seguramente lo mencionado anteriormente impactara en las fechas planificadas teniendo que postergarlas o realizar re entregas posteriores. 
Lo que observamos también es que no existe un margen de tiempo prudencial dedicado exclusivamente a realizar pruebas, esto lo mencionamos porque quizás si el equipo de desarrollo no continuara liberando funcionalidades para probar el equipo de QC se podría concentrar en probar las funcionalidades que ya han sido liberadas en profundidad para evitar continuar retrasasandose. \\

\textbf{Acciones correctivas} \\
En la situación en la que nos encontramos proponemos como principales acciones correctivas lo siguiente:
1.Replanificar las fechas y términos  de entrega. Consideramos que al ritmo actual de trabajo no llegamos a cumplir con los hitos pautados. La replanificacion puede estar pautada en terminos de menos funcionalidades a entregar , sin necesidad de realizar ajustes significativos en las fechas.
2.Mejorar la capacidad del equipo de QC para probar y liberar funcionalidades.
3.Mejorar la calidad del código liberado por el equipo de desarrollo.
4.Reubicar recursos del equipo de desarrollo en el equipo de QC. Esto va de la mano con plantear menos funcionalidades entregadas, pero asegurar que las entregadas esten probadas y funcionando bien.

